home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-12 / vir04002.zip / VIR04002.TXT < prev   
Text File  |  1991-01-03  |  28KB  |  640 lines

  1. From wang!elf.wang.com!ibm1.cc.lehigh.edu!virus-l Wed Jan  2 21:58:47 1991 remote from tosspot
  2. Received: by tosspot (1.63/waf)
  3.     via UUCP; Thu, 03 Jan 91 08:07:18 EST
  4.     for lee
  5. Received: from somewhere by elf.wang.com id aa29693; Wed, 2 Jan 91 21:58:46 GMT
  6. Received: from IBM1.CC.Lehigh.EDU by uunet.UU.NET (5.61/1.14) with SMTP 
  7.     id AA01551; Wed, 2 Jan 91 14:17:59 -0500
  8. Message-Id: <9101021917.AA01551@uunet.UU.NET>
  9. Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 7379; Wed, 02 Jan 91 14:14:19 EST
  10. Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer R2.05) with BSMTP id
  11.  7553; Wed, 02 Jan 91 14:13:59 EST
  12. Date:         Wed, 2 Jan 91 14:08:55 EST
  13. Reply-To: VIRUS-L@ibm1.cc.lehigh.edu
  14. Sender: Virus Discussion List <VIRUS-L@lehiibm1.bitnet>
  15. From: "The Moderator Kenneth R. van Wyk" <krvw@cert.sei.cmu.edu>
  16. Subject:      VIRUS-L Digest V4 #2
  17. Comments: To: VIRUS-L@IBM1.CC.LEHIGH.EDU
  18. To: Multiple recipients of list VIRUS-L <VIRUS-L%LEHIIBM1@uunet.uu.net>
  19.  
  20. VIRUS-L Digest   Wednesday,  2 Jan 1991    Volume 4 : Issue 2
  21.  
  22. Today's Topics:
  23.  
  24. VIRUS-L administrivia
  25. Various Comments
  26. Re: Job Market (PC)
  27. Antiviral evaluation guidelines
  28. FPROT review (PC)
  29.  
  30. VIRUS-L is a moderated, digested mail forum for discussing computer
  31. virus issues; comp.virus is a non-digested Usenet counterpart.
  32. Discussions are not limited to any one hardware/software platform -
  33. diversity is welcomed.  Contributions should be relevant, concise,
  34. polite, etc.  Please sign submissions with your real name.  Send
  35. contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
  36. VIRUS-L at LEHIIBM1 for you BITNET folks).  Information on accessing
  37. anti-virus, documentation, and back-issue archives is distributed
  38. periodically on the list.  Administrative mail (comments, suggestions,
  39. and so forth) should be sent to me at: krvw@CERT.SEI.CMU.EDU.
  40.  
  41.    Ken van Wyk
  42.  
  43. ---------------------------------------------------------------------------
  44.  
  45. Date:    Wed, 02 Jan 91 08:57:35 -0500
  46. From:    Kenneth R. van Wyk <krvw@cert.sei.cmu.edu>
  47. Subject: VIRUS-L administrivia
  48.  
  49. Happy New Year everyone!  In case you haven't noticed already, we're
  50. now up to VIRUS-L volume number 4.  I've updated the archives on
  51. cert.sei.cmu.edu to reflect this.  The pub/virus-l/archives/1990
  52. directory now contains the entire volume 3 set, and there's a new
  53. directory for 1991 (volume 4).
  54.  
  55. I hope everyone had a pleasant holiday season.  I kept myself busy
  56. downstairs in my brewery (read: basement).  :-P  Any other homebrewers
  57. out there?
  58.  
  59. Cheers,
  60.  
  61. Ken
  62.  
  63. ------------------------------
  64.  
  65. Date:    23 December, 1990
  66. From:    Padgett Peterson <padgett%tccslr.dnet@uvs1.orl.mmc.com>
  67. Subject: Various Comments
  68.  
  69. Note: Thanks to flakey routing have missed posts 194-203. Apolgise
  70.       for not responding to comments in the interim. Happy Christmas.
  71.  
  72. >From:    jmolini@nasamail.nasa.gov (James E. Molini)
  73.  
  74. >From what I have seen over the years, anyone who ever loaded a key
  75. >into a piece of crypto gear has called themselves a Computer Security
  76. >Expert at one time or another...
  77. >So what does it take to be competitive in this field?  It takes at
  78. >least a bachelor's degree in Computer Science and a strong background
  79. >generally in security.
  80.  
  81. Am reminded of the quip attributed to Mozart about what it took to
  82. write an opera. When given an answer that would require the better
  83. part of thiry years, the inquirer said "But Herr Mozart, you wrote
  84. your first opera at sixteen." to which the composer replied, "Ah yes,
  85. but I did not have to ask."
  86.  
  87. Having cut many a KG-13/KY-26 card & possessing an ME degree (from
  88. GMI), this would place me in the first category, however, I did not
  89. ask anyone (besides, who could you ask in 1966 ?) & feel there is a
  90. point that needs to be made. At present, there are really two
  91. different computer security fields: the first which Mr. Molini appears
  92. to address is the traditional multi-user mainframe which has access
  93. control as its primary requirement and provides insulation between
  94. users and applications. In most cases the user has neither concern nor
  95. care where WordPerfect resides, the system managers take care of this.
  96. PCs are another story altogether.
  97.  
  98. Here there is no access control or partitioning other than a pseudo
  99. one.  The user and any application called can do anything it/he/she
  100. wants. There is no RACF or CA/Top Secret and no user/kernel
  101. separation. Since mainframe manufacturers make the innards of the O/S
  102. a secret from the general public, often just a good knowlege of the
  103. package in use is all that is necessary.  (Though RACF is the only
  104. security system I know of that will tell you where its holes are and
  105. not trigger a violation for asking.)
  106.  
  107. To de-virus a PC (not just using CLEAN), the technician must
  108. understand the iapx80X86 machine code at hex and assembly language,
  109. operation of the BIOS, and the steps of loading a PC. Obviously the
  110. writers of JOSHI had some coaching on this as the first level mistakes
  111. are not made. These are entirely different skills than are generally
  112. needed on a mainframe. I know of few places outside of defense
  113. contractors where computer architecturists are still being utilized
  114. (and to anyone who has ever been stuck with making a
  115. Mil-Std-1750A/Jovial system work, my condolences but you probably have
  116. the right skills.)
  117.  
  118. The biggest difference even with a unix environment is that in the PC
  119. (and the MAC) environment things happen at such a low level that
  120. little information is available (other than in fifty or sixty feet of
  121. books at BookStop) and few bother to read it (did my bibliogaphy of a
  122. few issues ago get posted ?)
  123.  
  124. Just for an example, many readers of Virus-L use VAXes (my favorite
  125. PC) but how many know CHME, CHMK, & CHMS ? Its just not necessary
  126. unlike REPNZ MOVSW or LODSB/STOSB that should throw up warning flags
  127. to an observer in a PC.
  128.  
  129. The point is that these are just not skills that are taught anywhere
  130. that I know of (possibly, I'll be pleasently surprised as when several
  131. people reported that Logic is still taught in a few institutions)
  132.  
  133. >I have to read Virus-L at home because I
  134. >have a "real" computer security job to go to every morning.  I am not
  135. >alone in this respect.  Most companies don't realize the amount of
  136. >"phantom dollars" they are spending on viruses today.  When they do,
  137. >we'll see a much more effective response to this problem.
  138.  
  139. Exactly ! Perhaps the problem is that management expects miracles
  140. because we keep delivering them. In any event, I expect that nothing
  141. much will happen until the lawyers get into the act with some massive
  142. "negligence" suits from either stockholders of attacked companies or
  143. customers who suffer loss. The the Snake-Oil salesmen will really
  144. decend upon us.
  145.  
  146.                 Enough,
  147.                     Padgett
  148.  
  149. These opinions are free and worth what you paid for them.
  150.  
  151. ------------------------------
  152.  
  153. Date:    24 Dec 90 11:05:18 +0000
  154. From:    frisk@rhi.hi.is (Fridrik Skulason)
  155. Subject: Re: Job Market (PC)
  156.  
  157.   DRAGON@RCN.BITNET writes:
  158.  
  159. >...  What kind of job market is there for computer programmers who
  160. >specialize on detecting and eliminating viruses from other systems?
  161. >Is it a job that one can make a decent living at?  What languages
  162. >(Computer) are best suited for combatting viruses?  And who
  163. >(Corporations) would hire a computer anti-hacker?  Thanks for all
  164. >your help.
  165.  
  166. Well...as I am one of the people who partially make a living out of
  167. fighting viruses, I have a few suggestions.
  168.  
  169. You can indeed make a decent living by fighting viruses, but it is hard to
  170. get rich.  Anyhow, there are three options:
  171.  
  172.     1 - writing and selling anti-virus software...it is possible, but
  173.             not easy...I just barely make enough money from my own programs
  174.             to continue writing them.  If you want to write such programs,
  175.         be warned...it is a difficult market and crowded...but if you
  176.             still want to try...here is what you need:
  177.  
  178.             Very good knowledge of assembly language...I am not talking
  179.             about a one-semester course or anything like that...you need
  180.             the kind of practice you get by writing assembly-language programs
  181.             for several years.
  182.  
  183.             Very good knowledge of the operating system in question - you
  184.             must know every documented call, and also quite a few of the
  185.             undocumented ones.
  186.  
  187.             Very good knowledge of the hardware...I/O ports, absolute
  188.             addresses etc.
  189.  
  190.         Decent knowledge of at lest one high level language...C or
  191.         Pascal recommended.
  192.  
  193.         Last, but not least...samples of most of the different viruses,
  194.         just to make sure your programs work.  On a PC this means nearly
  195.             350 different viruses...and a lot of work...
  196.  
  197.             The problem of course is to sell your program...having the best
  198.             anti-virus program is not of much use, if nobody knows of
  199.         its existence.
  200.  
  201.     2 - Anti virus service...no programming, you just help people clean
  202.         up viruses and recover from attacks.  This also involves
  203.             installing anti-virus programs.
  204.  
  205.     3 - Writing about viruses...write a book...or magazine articles or
  206.         anything.
  207.  
  208.         The problem, in my opinion, is that all the virus-books available
  209.         only increase the "popularity" of viruses, leading to the writing
  210.         of still more viruses.
  211.  
  212. - -frisk
  213.  
  214. Fridrik Skulason      University of Iceland  |
  215. Technical Editor of the Virus Bulletin (UK)  |  Reserved for future expansion
  216. E-Mail: frisk@rhi.hi.is    Fax: 354-1-28801  |
  217.  
  218. ------------------------------
  219.  
  220. Date:    Sun, 23 Dec 90 00:06:04 -0800
  221. From:    Robert Slade <USERQBPP@SFU.BITNET>
  222. Subject: Antiviral evaluation guidelines
  223.  
  224. Attached herewith is an article outlining the different classes of
  225. anti-viral software, and features to check for in each class.  This is
  226. meant as an introduction to the anti-viral product reviews, which will
  227. be coming out every few weeks for the next little while.  (The first
  228. review should be included in this same issue of the digest.  It is
  229. for FPROT.)
  230.  
  231. [Ed. A wholehearted thanks for the effort, Robert!  I normally just
  232. place articles of this length into the archives with a pointer to them
  233. in the digests, but I'm making an exception in this case.  In
  234. addition, I'm placing this and any other reviews in the archives, on
  235. cert.sei.cmu.edu in pub/virus-l/docs/reviews.]
  236.  
  237. Reviewing Anti-virus Products
  238.  
  239. Robert Michael Slade
  240. 3118 Baird Road
  241. North Vancouver, B. C.
  242. V7K 2G6
  243. (604) 988-4097
  244.  
  245.  
  246. I am quite certain that the first question to do with "anti-
  247. viral" or other data security packages will be "which one is
  248. best?"  This ignores two vitally important points.  The first is
  249. that "the best" may not be good enough by itself.  No security
  250. force would ever pick "the best" guard, and then leave him to
  251. guard an entire refinery by himself.
  252.  
  253. The second point is that, even within the limited realm of anti-
  254. viral programs, data security software operates in many different
  255. ways.  Thus, one type of security may be better in one situation,
  256. while another variety may be better in a different environment.
  257. (Which make better guards, dogs or men?  Wise security firms use
  258. both.)  There are basically five "classes" of anti-viral
  259. packages; vaccines, change detection software, operation
  260. restricting software, encrypting software and scanners.  Each
  261. type has it's own strengths and weaknesses.
  262.  
  263. Vaccine
  264.  
  265. Vaccine software is memory resident and watches for "suspicious"
  266. activity.  It may, for example, check for any calls to "format" a
  267. disk while a program other than the operating system is "in
  268. control".  It may be more sophisticated, and check for any
  269. program that attempts to alter or delete a program file.
  270.  
  271. It is, however, very hard to tell the difference between a word
  272. processor updating a file and a virus infecting a file.  Vaccine
  273. programs may be more trouble than they are worth by continually
  274. asking for confirmation of valid activities.  They also may be
  275. bypassed by viri that do "low level" programming rather than
  276. using the standard operating system "calls".
  277.  
  278. It is very difficult to specify, in advance, what you should
  279. check for in vaccine software, since the developers are loath to
  280. state, in specific detail, exactly what the vaccine will be
  281. checking for.  (This reluctance is understandable: if a vaccine
  282. developer "advertises" exactly what the product checks for, virus
  283. or "trojan" writers will simply use another route.)  Vaccine
  284. software should be thoroughly tested in a "real" working
  285. environment (one that uses all the programs you normally do, in
  286. the ways you normally use them) for some time in order to ensure
  287. that the vaccine does not conflict with "normal" operation.
  288.  
  289. Change detection software
  290.  
  291. Change detection software examines system and/or program files
  292. and configuration, stores the information, and compares it
  293. against the actual configuration at a later time.  Most of these
  294. programs perform a "checksum" or "cyclic redundancy check" (CRC)
  295. that will detect changes to a file even if the length is
  296. unchanged.
  297.  
  298. The disadvantages of this system are 1) it provides no
  299. protection, but only notification after the fact, 2) some change
  300. detection software is limited to operating system software only,
  301. 3) you must "inform" the software of any changes you make in the
  302. system and 4) change detection software may not "see" changes
  303. made by "stealth" viri.  Some versions of this software run only
  304. at "boot time", others check each program as it is run.  Some of
  305. these programs attach a small piece of code to the programs they
  306. are "protecting", and this may cause programs which have their
  307. own change detection features to fail.
  308.  
  309. A major factor in judging change detection systems is that of
  310. installation and operation time.  Since the system will be
  311. calculating "signatures" of all (or all selected) programs on
  312. your system (sometimes with very sophisticated algorithms), it
  313. may take some time to install, and to "re-install" each time you
  314. make a change to your system.  It may also take an unacceptable
  315. amount of time to check out a program before it will allow it to
  316. run.
  317.  
  318. You should also find out how and where the security system will
  319. "store" the necessary program signatures, particularly if you run
  320. programs from diskette.  Also, since these types of systems are
  321. heavily influenced by the mini- and mainframe data security
  322. community, it is important to query whether they have made
  323. provisions for checking for boot sector viri, or other viri that
  324. may not show up as changes to program files.
  325.  
  326. Operation restricting software
  327.  
  328. Operation restricting software is similar to vaccine software,
  329. except that instead of watching for suspicious activities it
  330. "automatically" prevents them.  As with mainframe security
  331. "permission" systems, some of these packages allow you to
  332. restrict the activities that programs can perform, sometimes on a
  333. "file by file" basis.
  334.  
  335. However, the more options these programs allow, the more time
  336. they will take to set up.  Again, the program must be modified
  337. each time you make a valid change to the system, and, as with
  338. vaccine programs, some viri may be able to evade the protection
  339. by using low level programming.
  340.  
  341. It is important, with this software, that the operator is given
  342. the option of "allowing" an operation.  It is also important that
  343. the operator be informed, not only that a particular program or
  344. operation should be halted, but also why.  There should not be
  345. too many "false alarms" generated by the software, and it would
  346. be helpful to have the option of "tuning" the software to be
  347. less, or more, sensitive to a given type of activity.
  348.  
  349. Encrypting software
  350.  
  351. Encrypting software writes programs and/or data onto your disks
  352. in a non-standard way  and then "decrypts" the program or file
  353. when you need to use it.  This means that if a virus does try to
  354. infect the system, it usually only scrambles the data and is
  355. easily detectable.  Used in conjunction with operation
  356. restricting software features, encrypting software essentially
  357. changes the whole operating environment, hopefully to one that a
  358. virus cannot survive in.
  359.  
  360. Again, there is the need to do a lot of work in setting up the
  361. protection system, and keeping it up to date when you make
  362. changes.  (It is also possible, if the system is not configured
  363. properly to begin with, to end up with a system that you cannot
  364. use and cannot repair.)  There are two major "holes" in the
  365. security of the system, 1) some part of the system must remain
  366. "unencrypted" and is therefore vulnerable to "attack" and 2) if
  367. you start with already infected files, the system will quite
  368. happily encrypt the virus and allow it to operate.
  369.  
  370. One vitally important feature to consider in encrypting software,
  371. particularly if it is coupled with operation restricting
  372. software, is the ability to recover if anything goes wrong.  Do
  373. you have a recoverable backup, or are all your backup files
  374. encrypted, and useless without the proper code?  Can you boot off
  375. a floppy to recover if your "security" program dies?  If you can
  376. boot off a floppy, what provisions guard against boot sector
  377. viri?
  378.  
  379. Scanners
  380.  
  381. Scanning software is, paradoxically, the least protective and
  382. most useful of anti-viral software.  These programs examine
  383. files, boot sectors and/or memory for evidence of viral
  384. infection.  They generally look for viral "signatures", sections
  385. of program code that are known to be in specific viri but not in
  386. most other programs.  Because of this, scanning software will
  387. only detect "known" viri, and must be updated regularly.  Some
  388. scanning software has "resident" versions that check each file as
  389. it is run, but most require that you run the software "manually".
  390. It is also the classic case of "bolting the door after the horse
  391. is gone" since "scanners" only find infections after they occur.
  392.  
  393. Why then, with all the disadvantages of scanning software, are
  394. they the most successful of anti-viral packages?  Generally
  395. speaking, it is because they force the user to pay attention to
  396. the system.  Again, when a user relies on one particular method
  397. of protection they are most vulnerable.
  398.  
  399. Scanning software should be able to identify the largest possible
  400. number of viri, and should be able to identify variations on the
  401. more important sections of code (that is, it should be able to
  402. "accept" the removal of text strings and other simple
  403. modifications that "bush league hackers" might make.)  For ease
  404. and speed of updating, the "signatures" should be stored in a
  405. separate file and there should be a source for the addition of
  406. new viral signatures to the file.  For security, both scanning
  407. software program and signature files should be renameable.
  408.  
  409. Areas scanned should include not only the identifiable program
  410. files, but all files, if necessary.  Scanners should have the
  411. ability to search the more common archiving formats as well,
  412. particularly those that support "self extraction" functions.
  413. Disk boot sector and hard disk partition boot records should be
  414. scanned, as well (in this day of stealth viri) as memory.
  415.  
  416. copyright 1990 Robert M. Slade
  417.  
  418. ------------------------------
  419.  
  420. Date:    Sun, 23 Dec 90 00:11:24 -0800
  421. From:    Robert Slade <USERQBPP@SFU.BITNET>
  422. Subject: FPROT review (PC)
  423.  
  424. Antiviral Protection Comparison Review
  425.  
  426. Company and product:
  427.  
  428. Fridrik Skulason
  429. Box 7180
  430. IS-127 Reykjavik
  431. Iceland
  432. frisk@rhi.hi.is
  433. F-PROT-Virus detection/protection/disinfection and utilities
  434.  
  435. Summary:
  436.  
  437. Highly recommended for any situation.  Best "value for cost" of
  438. any package reviewed to date.  Installation may require knowledge
  439. of MS-DOS.
  440.  
  441. Cost
  442. Site license
  443.     Education      $1(US) per computer (minimum $20)
  444.     Other          $2(US) per computer
  445.  
  446. Rating (1-4, 1 = poor, 4 = very good)
  447.       "Friendliness"
  448.             Installation      2
  449.             Ease of use       3
  450.             Help systems      2
  451.       Compatibility           4
  452.       Company
  453.             Stability         2
  454.             Support           3
  455.       Documentation           2
  456.       Hardware required       4
  457.       Performance             3
  458.       Availability            3
  459.       Local Support           ?
  460.  
  461. General Description:
  462.  
  463. Of the five classes of anti-viral systems, the only one that
  464. FPROT does not provide for is encryption.  It provides vaccine
  465. (F-LOCK), change detection (F-OSCHK, F-XLOCK), operation
  466. restricting (F-DLOCK, F-XCHK) and scanning (F-DRIVER.SYS, F-FCHK,
  467. F-DISINF, F-SYSCHK) protection.  The package also includes
  468. various system information utilities
  469.  
  470.  
  471.                   Comparison of features and specifications
  472.  
  473.  
  474.  
  475. User Friendliness
  476.  
  477. Installation
  478.  
  479. The installation of FPROT is not a one step process, since the
  480. package contains a number of different programs for different
  481. protective purposes.  The user must decide which programs to use,
  482. and therefore the installation must be done in stages.
  483.  
  484. There is no installation program, but the documentation does have
  485. a separate installation file.  This file states that the user
  486. should have a knowledge of MS-DOS, and that is likely necessary.
  487. The installation process, however, is described clearly, and is
  488. quite complete.
  489.  
  490. The package is distributed as "shareware", and therefore any user
  491. who obtains it is likely to have the necessary skills for its
  492. installation.
  493.  
  494. The installation procedure does "allow" one possible point of
  495. infection if the computer is infected when the program is
  496. installed, but the program will immediately detect the infection
  497. unless it is not found in the signature file.  Since the program
  498. is "posted" in archived format, the user should be able to clear
  499. the infection and start with fresh files.
  500.  
  501. Ease of use
  502.  
  503. All the functions of FPROT are found in different programs, and
  504. all are invoked from the command line, so when a user knows what
  505. function is desired it is a simple matter to obtain it.  Only two
  506. of the programs have any "switches" other than file or path
  507. specification.
  508.  
  509. Help systems
  510.  
  511. As all packages are invoked from the command line for a single
  512. function, there is no need for "online" help.  When programs are
  513. called without necessary file or path specifications, a message
  514. explaining what is needed appears.
  515.  
  516. Compatibility
  517.  
  518. The various programs have been tested on a wide variety of
  519. computers, and have not created any problems with hardware, even
  520. on systems that have serious problems with TSR programs.
  521.  
  522. The documentation lists a number of "contra-indicated" software
  523. packages and systems which may conflict with program operations.
  524. However, in six months of testing, no normal character based
  525. program or TSR has been found to conflict with any FPROT program.
  526.  
  527. Company Stability
  528.  
  529. Unfortunately, the future of FPROT is currently in doubt.  It may
  530. continue as a shareware product, or it may be sold to commercial
  531. interests.
  532.  
  533. Company Support
  534.  
  535. No problems have been encountered with the program so far.
  536. Fridrik Skulason is available through the Internet, and replies
  537. to queries can be expected within a week or less.
  538.  
  539. Documentation
  540.  
  541. Being shareware, the package has no printed documentation.  The
  542. text files included with the programs are very clear and
  543. thorough, and provide an excellent primer on virus functions and
  544. protection.  Novice users may, however, find the USAGE.TXT
  545. document to be daunting.  Fortunately only the INSTALL.TXT
  546. document is required to use the product.  The virus listings are
  547. comprehensive as to the number of viri, if somewhat less
  548. technical and detailed than the Brunnstein and Hoffman listings.
  549.  
  550. Hardware Requirements
  551.  
  552. No special hardware is required.
  553.  
  554. Performance
  555.  
  556. During testing, FPROT has consistently identified more viri than
  557. the "current release" of any other product.  It has occasionally
  558. given a "false positive", but only in the case of identifying a
  559. definite virus with two different names, or when scanning another
  560. virus scanning product.  FPROT is generally slower at scanning,
  561. and the separate signature file renders it slower still, but the
  562. separate file also allows new signatures to be added without
  563. waiting for a product upgrade.
  564.  
  565. The user is in control of FPROT at all times, with the exception
  566. that F-DRIVER.SYS will not allow the boot sequence to continue in
  567. the case of a boot sector infection at startup.
  568.  
  569. FPROT, in six months of testing, has not given a false positive
  570. alarm on any normal program, nor has it interfered with any
  571. normal program operation.
  572.  
  573. Local Support
  574.  
  575. Since FPROT is shareware, there are no local dealers to obtain
  576. support from.  FPROT has fewer users in North America than SCAN,
  577. and so local help may be harder to obtain, but the documentation
  578. should make up any deficiencies.
  579.  
  580. For users in Europe, FPROT is available as a commercially
  581. distributed product.  For those in Canada, some support is
  582. available through the new SUZY Information Service, through
  583. INtegrity, the data security and anti-viral IN (Information
  584. Network.)
  585.  
  586. Support Requirements
  587.  
  588. In a situation where technical support is available for the user
  589. base, installation may best be performed by the support group.  A
  590. corporate environment will likely wish to have security policies,
  591. and support for the package in addition to installation would
  592. best be coordinated by this group.
  593.  
  594.                                  General Notes
  595.  
  596.  
  597. Because of its "shareware" distribution, FPROT is best compared
  598. against John McAfee's SCAN program.
  599.  
  600. FPROT is definitely the more complex package, but that is because
  601. of far greater functionality.  SCAN, in it's most recent
  602. releases, has offered a minor disinfection feature, but for most
  603. disinfection one must obtain, separately and at separate cost,
  604. the CLEAN and/or the older M-DISK programs.  Resident
  605. "vaccination" is also available, but again it is in the separate
  606. SENTRY or VSHIELD programs.  Finally, for use of any of these on
  607. a network, NETSCAN is required.  None of the SCAN family of
  608. programs offers the system information utilities that FPROT comes
  609. bundled with.
  610.  
  611. FPROT is kept up to date with regular additions to the signature
  612. file, and constant improvements to the program.  SCAN versions
  613. are released at approximately the same frequency as FPROT, but in
  614. a six month trial period from June to November of 1990, FPROT
  615. releases consistently identified more viri, and with greater
  616. accuracy than did the "same level" releases of SCAN.  (During
  617. this period, McAfee had to release four "bug fix" versions,
  618. Skulason only one.)  Fridrik Skulason also publishes the
  619. signatures of new viri on the VIRUS-L (Usenet comp.virus)
  620. distribution lists, and signature files can be updated between
  621. releases.
  622.  
  623. FPROT, distributed as shareware, is free for individual users.
  624. For a $15 US fee, Fridrik Skulason will mail out a "registered"
  625. copy.  The cost of the SCAN program is apparently subject to
  626. negotiation, but the "list price" in the documentation,
  627. shareware, for home use, is $25 US.  For the full set of four
  628. programs (SCAN, CLEAN, SENTRY and VSHIELD, not including NETSCAN)
  629. mailed on disk from McAfee Associates the cost is $119 US.  Site
  630. licenses for FPROT are available for $2 US per CPU, $1 for
  631. educational institutions.  Site licenses for SCAN alone are
  632. quoted at $8 US per CPU.
  633.  
  634. copyright 1990 Robert M. Slade
  635.  
  636. ------------------------------
  637.  
  638. End of VIRUS-L Digest [Volume 4 Issue 2]
  639. ****************************************
  640.